1. Field of the Invention
This invention relates generally to diagnostic testing of computers and computer networks in transportation vehicles, and, more particularly, to an improved device and method for communicating with an automobile's internal computer networks.
2. Description of Related Art
Modern transportation vehicles, such as automobiles, increasingly employ computer systems for managing communications, safety, and control. New automobiles typically contain 30 or 40 different computers. These computers are generally linked together to form one or more computer networks. An automobile's computers communicate over these networks via various network protocols. Different types of automobiles employ different protocols, which are generally proprietary to the automobile's manufacturer. Examples of automotive network protocols include CAN, UART, or SAE J1850.
Technicians require access to an automobile's computer networks to configure the automobile's computers and to run diagnostics. Access is provided via one or more access ports, which are generally located under the dashboard. The access ports are physical connectors that are accessible to a technician and provide taps into the automobile's networks. An external device can be connected to the access port. Under a technician's control, the device can be made to interact with the automobile's networks, or any of its computers, according to the respective network protocols. Diagnostic information can therefore be acquired. The device is generally programmable for configuring the automobile's computers, or for running a test program on the automobile's networks, computers, and/or the functional subassemblies that the computers control. Information about the status and operation of the automobile can be read back, analyzed, and used to indicate proper operation or to diagnose problems.
FIG. 1 shows a standard arrangement for testing automotive computer networks. A host device communicates with an automobile 112 via a Vehicle Communications Interface, or “VCI,” 110. The VCI 110 has a flexible design that enables it to communicate with different types of host computing devices, such as a laptop computer 116, a personal data assistant (PDA) 118, or a computer workstation 128. Other types of computing devices can be used. It can communicate with the host using different networking technologies, such as 10/100 Ethernet, IEEE 802.11 or Bluetooth.
The host computer (e.g., any of laptop 116, PDA 118, and workstation 120) need not be a specialized system. The host computer generally runs a mainstream operating system, such as Windows®, Linux, or PalmOS®. It generally communicates with the VCI 110 using TCP/IP, just as it does with other devices on its network or over the Internet.
FIG. 2 shows a block diagram of a conventional VCI 200. The VCI 200 can be used in in the standard arrangement of FIG. 1. The VCI 200 includes a CPU 210. The CPU 210 runs software for interacting with automotive networks. The CPU 210 can communicate with a host computer using a hard-wired connection (e.g., 10/100 Ethernet, 122), or using a wireless path (e.g., wireless LAN connection, 124).
The VCI 200 communicates with different types of automotive networks, to accommodate the configuration and diagnostic needs of various vehicles. It generally includes a number of Media Access Controllers, or “MACs.” Each MAC is a digital circuit that supports 2-way communication with a particular network protocol. For example, the VCI 200 includes a CAN MAC 220, for communicating with CAN protocol, a UART MAC 222 for communicating with UART protocol, and a SAE J1850 MAC 224 for communicating with SAE J1850 protocol. The MACs are generally implemented as Application Specific Integrated Circuits (ASICs). A different ASIC is provided for each type of MAC. The types of MACs employed in a particular VCI 200 depends upon the types of networks the VCI communicates with. Therefore, the types of MACs may be different from those shown in FIG. 2, and the VCI 200 may include additional MACs.
The actual signals passed on an automotive network generally have voltage levels that are different from those produced or received for the respective MAC. Levels must therefore be shifted before they are sent out to the automotive network or before the MAC receives them. Physical shifters, CAN PHY 230, UART PHY 232, and SAE J1850 PHY 234, accomplish the requisite level shifting for both incoming and outgoing signals.
A Pin MUX 240 is provided at the output of the VCI 200 to route signals to appropriate conductors of the cable 114. This capability allows the VCI to accommodate access ports that have different pin assignments.
The VCI 200 sends messages out over an automotive network using generally the following process. In response to a directive from a host computer, the CPU 210 prepares a message for transmission over the automotive network. The CPU 210 sends data to the particular MAC that handles the type of automotive network to be used. For instance, if the automotive network to be used follows the CAN protocol, the CPU 210 outputs the message to the CAN MAC 220. The CAN MAC 200 processes the data from the CPU 210 and converts it into a format that is consistent with the CAN protocol. The CAN PHY 230 adjusts the levels of the signals provided by the CAN MAC 220, and the Pin MUX 240 routes the shifted signals to appropriate pins of the cable 114. The VCI 200 thus manages several tasks, including data generation, data formatting, physical level shifting, and physical pin assignments for transmitted messages.
The VCI 200 receives messages from the automotive network using generally the reverse of the process described above. A message arrives over the cable 114. The Pin MUX 40 routes the message to the appropriate level shifter, here CAN PHY 230. The level shifter changes the levels of the signals carrying the message to be consistent with the voltage levels of the CAN MAC 220. The CAN MAC 220 receives the shifted signals, which are expressed in the CAN protocol, and converts them to data, which are sent to the CPU 210. The CPU 210 interprets the received message and takes appropriate action. This may include sending a result back to the host computer.
It is well known that many transactions in automotive networks require real time responses. For example, the receipt of certain messages must be acknowledged within a set amount of time to prevent an error or some other undesirable condition. In the VCI 200, the CPU 210 has the task of generating the requisite response. The requirement to perform this task places certain constraints on the design of the CPU 210. For example, the CPU 210 must be able to respond to incoming messages substantially in real time. This means that the CPU 210 must generally run a Real Time Operating System (RTOS).
RTOS's involve certain drawbacks. For example, the mainstream operating systems on the market today are not RTOS's, and software programs developed for mainstream operating systems are not readily adaptable for running on RTOS's. Consequently, software is often required to be developed and maintained specifically for an RTOS by the VCI supplier. The lack of available software for RTOS's is particularly troublesome because new host technologies are frequently introduced, such as wireless LAN and USB. Supporting these technologies with a VCI running an RTOS thus requires frequent and intensive software efforts.
Another problem arises if Virtual Private Network (VPN) support is needed. Typically, this support is available only for mainstream operating systems and is not available for RTOS's.
To overcome these drawbacks, the VCI 300 of FIG. 3 has been proposed. The VCI 300 includes, as a component, the Conventional VCI 200 of FIG. 2. However, the VCI 300 also includes a VCI server 310 between the host and the Conventional VCI 200. The VCI server 310 communicates with the Conventional VCI 200 over a network, such as Ethernet. The VCI server 310 also communicates with the host and runs a mainstream operating system, such as Windows or Linux. The VCI server 310 can thus run mainstream software for supporting new networking technologies. It can also be configured with VPN. Because the VCI server 310 is interposed between the Conventional VCI 200 and the host, the task of networking to the host is moved from the Conventional VCI 200, where it is difficult to support, to the VCI server 310, where support is much more convenient. Custom RTOS implementations supporting new networking technologies are thus not required.
Although the VCI 300 greatly reduces the effort needed to incorporate new technologies, it significantly increases the cost of the VCI. The VCI server 310 is typically a microprocessor, which, along with the requisite memory and peripherals, adds at least $100 beyond the cost of the Conventional VCI 200. Diagnostic equipment for automobiles is highly cost sensitive, and the need for the added microprocessor reduces the appeal of an otherwise attractive solution.
What is needed is a VCI that provides the benefits of a mainstream operating system without the added cost.